Release 10.1A: OpenEdge Getting Started:
WebSpeed Essentials

Firewall configuration

Using a firewall poses additional configuration issues because you must configure the firewall to allow communications between the OpenEdge server host machines on particular ports using TCP or UDP protocols. In OpenEdge Application Server: Developing WebSpeed Applications, the entire round-trip request is shown. All of these messages must go through the firewall.

Figure 4–13 illustrates which ports must be open and what protocols the messages use.

Figure 4–13: Firewall configuration

Note: The firewall fire2 has two network cards, one for the Demilitarized Zone (DMZ) and one for the Internal network. Each of these has its own IP address, as shown.

In the following sections the hosts file is mentioned. On UNIX or Linux, this is located at /etc/hosts and in Windows NT and later at C:\WINDOWS\system32\drivers\etc\hosts.

The WebSpeed Messenger ubroker.properties file must have the minNSClientPort and maxNSClientPort settings modified in the [WebSpeed.Messengers] configuration, as shown in Example 4–4. The port range must be big enough to cope with all the potential simultaneous requests from the Internet. In this case, there are 20 ports available. You can make this range bigger if needed. Also, you must change the setting for the NameServer to point to the correct host.

Example 4–4: Configuring ubroker.properties file for firewall 

[WebSpeed.Messengers] . . minNSClientPort=5680 maxNSClientPort=5699 controllingNameServer=InternetNS . . [NameServer.InternetNS] . . hostName=inet_ns location=remote portNumber=5678 . .

You must configure the following:

Between the Internet and Web server webserv1:
Allow inbound and outbound traffic from the Internet on port 80 (the default for HTTP) to the Web server. This is a standard configuration on most firewalls. If you are using HTTP/S (HTTP over SSL), then the default port is 443.
Between the Web server (Messenger) and NameServer:
Allow UDP from IP Address 1.1.1.1 to 5.5.5.5 on port 5678. This is the inbound NameServer request traffic.
Allow UDP from IP Address 5.5.5.5 to 1.1.1.1 on ports 5680 to 5699 inclusive (assuming the above settings in the ubroker.properties file). This is the outbound NameServer response traffic as specified in the Messenger’s ubroker.properties file on the Web server.
Between the Web server (Messenger) and WebSpeed broker:
Allow TCP from IP Address 1.1.1.1 to 4.4.4.4 on port 7800 for the inbound request.
Allow TCP from IP Address 4.4.4.4 to 1.1.1.1 on port 7800 for the outbound reply.
Between the Web server (Messenger) and WebSpeed agents:
Allow TCP from IP Address 1.1.1.1 to 4.4.4.4 on ports 7801 to 7805 inclusive for the inbound request.
Allow TCP from IP Address 4.4.4.4 to 1.1.1.1 on port 7801 to 7805 inclusive for the outbound reply.

Most firewalls accomplish this by using “port forwarding.” This means that when the firewall receives a request from a host on a certain port in the DMZ, it is passed through to a particular host on the internal network. When the webserv1 machine makes a request to the NameServer, it cannot see IP address 5.5.5.5 directly, and it has to pass the request to the firewall machine fire2. The firewall then makes the request on the internal network to IP address 5.5.5.5 on its behalf. When the response comes back from the NameServer to the firewall, the firewall will send it on to the Messenger on the DMZ network. As an analogy, think of the firewall as a language interpreter where the WebSpeed Messenger speaks English and the NameServer speaks German. The Messenger needs to talk to the NameServer but cannot do so directly, so it forwards the request to the interpreter who, in turn, makes a request to the NameServer on the Messenger’s behalf. The response is given to the interpreter by the NameServer, who then forwards it to the Messenger.

This is achieved by setting the hosts file on webserv1 to have the host inet_ns set to 2.2.2.2, as shown below. When the Messenger looks for host inet_ns, it uses the IP address 2.2.2.2, which is the firewall host fire2, as shown:

127.0.0.1 localhost 2.2.2.2 inet_ns

Note: You do not must have an entry for fire2 in the hosts file as the DMZ machines never communicate with it by name; DMZ machines believe that communication with other machines never travels beyond the internal network.

Similarly, the Messenger cannot communicate directly to the WebSpeed server host webspeed1 at IP address 4.4.4.4 either. So, another entry needs to be made in the hosts file to make the Messenger communicate with the firewall instead of the “real” host, as shown:

127.0.0.1 localhost 2.2.2.2 inet_ns webspeed1

Because of this, you cannot use the default setting for the WebSpeed broker’s registration mode. The default is to use the broker host IP Address. If you do this, the NameServer will tell the Messenger to try to contact the broker on IP address 4.4.4.4, which is not a valid IP address in the DMZ, and it will appear as if the broker has not responded. You must set the broker to register using a defined host name, in this case webspeed1. When the NameServer responds this time, it tells the Messenger to try to connect using the host name webspeed1. The Messenger asks the operating system on its host for the IP address of webspeed1. Since the address set in the hosts file is 2.2.2.2, the Messenger uses that address when it is returned. The firewall then gets the request and passes it through. Figure 4–14 shows this configuration setting.

Figure 4–14: Setting host name

Note: The NameServer and WebSpeed server hosts do not need the firewall IP address in their hosts file because they only respond to requests and do not make them.